프론트엔드 보안: XSS 방어와 콘텐츠 보안 정책(CSP)

오늘날의 웹 개발 환경에서 프론트엔드 보안은 매우 중요합니다. 웹 애플리케이션이 점점 더 복잡해지고 상호작용이 많아지면서, 다양한 공격, 특히 크로스 사이트 스크립팅(XSS)에 더 취약해지고 있습니다. 이 글에서는 XSS 취약점을 이해하고 완화하는 방법과 강력한 방어 메커니즘으로서 콘텐츠 보안 정책(CSP)을 구현하는 방법에 대한 종합적인 가이드를 제공합니다.

크로스 사이트 스크립팅(XSS) 이해하기

XSS란 무엇인가?

크로스 사이트 스크립팅(XSS)은 신뢰할 수 있는 정상적인 웹사이트에 악성 스크립트가 주입되는 인젝션 공격의 한 유형입니다. XSS 공격은 공격자가 웹 애플리케이션을 사용하여 다른 최종 사용자에게 일반적으로 브라우저 측 스크립트 형태의 악성 코드를 전송할 때 발생합니다. 이러한 공격을 허용하는 결함은 매우 널리 퍼져 있으며, 웹 애플리케이션이 사용자로부터 받은 입력을 검증하거나 인코딩하지 않고 생성하는 출력 내에서 사용하는 모든 곳에서 발생할 수 있습니다.

사용자들이 댓글을 게시할 수 있는 인기 있는 온라인 포럼을 상상해 보세요. 만약 포럼이 사용자 입력을 제대로 처리하지 않는다면, 공격자는 댓글에 악성 자바스크립트 스니펫을 주입할 수 있습니다. 다른 사용자가 해당 댓글을 볼 때, 악성 스크립트가 그들의 브라우저에서 실행되어 쿠키를 훔치거나, 피싱 사이트로 리디렉션하거나, 웹사이트를 변조할 수 있습니다.

XSS 공격의 유형

• 반사형 XSS(Reflected XSS): 악성 스크립트가 단일 요청에 주입됩니다. 서버는 HTTP 요청에서 주입된 데이터를 읽고 사용자에게 다시 반사하여 사용자의 브라우저에서 스크립트를 실행시킵니다. 이는 종종 악성 링크가 포함된 피싱 이메일을 통해 이루어집니다.
• 저장형 XSS(Stored XSS): 악성 스크립트가 대상 서버(예: 데이터베이스, 포럼 게시물, 댓글 섹션)에 저장됩니다. 다른 사용자가 저장된 데이터에 접근할 때 스크립트가 그들의 브라우저에서 실행됩니다. 이 유형의 XSS는 다수의 사용자에게 영향을 줄 수 있어 특히 위험합니다.
• DOM 기반 XSS(DOM-based XSS): 취약점이 클라이언트 측 자바스크립트 코드 자체에 존재합니다. 공격은 희생자의 브라우저에서 DOM(문서 객체 모델)을 조작하여 악성 스크립트를 실행시킵니다. 이는 종종 URL이나 다른 클라이언트 측 데이터를 조작하는 것을 포함합니다.

XSS의 영향

성공적인 XSS 공격의 결과는 심각할 수 있습니다:

• 쿠키 탈취: 공격자는 사용자 쿠키를 훔쳐 계정 및 민감한 정보에 접근할 수 있습니다.
• 계정 하이재킹: 훔친 쿠키로 공격자는 사용자를 사칭하고 대신하여 행동을 수행할 수 있습니다.
• 웹사이트 변조: 공격자는 웹사이트의 외관을 수정하여 허위 정보를 퍼뜨리거나 브랜드의 명성을 훼손할 수 있습니다.
• 피싱 사이트로 리디렉션: 사용자는 로그인 정보를 훔치거나 멀웨어를 설치하는 악성 웹사이트로 리디렉션될 수 있습니다.
• 데이터 유출: 페이지에 표시되는 민감한 데이터가 도난당하여 공격자의 서버로 전송될 수 있습니다.

XSS 방어 기법

XSS 공격을 방어하기 위해서는 입력값 검증과 출력 인코딩 모두에 초점을 맞춘 다층적인 접근 방식이 필요합니다.

입력값 검증

입력값 검증은 사용자 입력이 예상되는 형식과 데이터 유형을 따르는지 확인하는 과정입니다. XSS에 대한 완벽한 방어책은 아니지만, 공격 표면을 줄이는 데 도움이 됩니다.

• 화이트리스트 검증: 허용되는 문자 및 패턴의 엄격한 집합을 정의합니다. 화이트리스트와 일치하지 않는 모든 입력을 거부합니다. 예를 들어, 사용자가 이름을 입력할 것으로 예상된다면 글자, 공백, 그리고 경우에 따라 하이픈만 허용합니다.
• 블랙리스트 검증: 알려진 악성 문자나 패턴을 식별하고 차단합니다. 그러나 블랙리스트는 종종 불완전하며 교묘한 공격자에 의해 우회될 수 있습니다. 일반적으로 블랙리스트 검증보다 화이트리스트 검증이 선호됩니다.
• 데이터 유형 검증: 입력이 예상되는 데이터 유형(예: 정수, 이메일 주소, URL)과 일치하는지 확인합니다.
• 길이 제한: 버퍼 오버플로우 취약점을 방지하기 위해 입력 필드에 최대 길이 제한을 둡니다.

예제 (PHP):

<?php $username = $_POST['username']; // 화이트리스트 검증: 영문, 숫자, 밑줄만 허용 if (preg_match('/^[a-zA-Z0-9_]+$/', $username)) { // 유효한 사용자 이름 echo "유효한 사용자 이름: " . htmlspecialchars($username, ENT_QUOTES, 'UTF-8'); } else { // 유효하지 않은 사용자 이름 echo "잘못된 사용자 이름입니다. 영문, 숫자, 밑줄만 허용됩니다."; } ?>

출력 인코딩 (이스케이핑)

이스케이핑이라고도 알려진 출력 인코딩은 특수 문자를 HTML 엔티티 또는 URL 인코딩된 형태로 변환하는 과정입니다. 이는 브라우저가 해당 문자를 코드로 해석하는 것을 방지합니다.

• HTML 인코딩: <, >, &, ", '와 같이 HTML에서 특별한 의미를 갖는 문자를 이스케이프합니다. PHP의 htmlspecialchars()와 같은 함수나 다른 언어의 동등한 메소드를 사용합니다.
• URL 인코딩: 공백, 슬래시, 물음표와 같이 URL에서 특별한 의미를 갖는 문자를 인코딩합니다. PHP의 urlencode()와 같은 함수나 다른 언어의 동등한 메소드를 사용합니다.
• 자바스크립트 인코딩: 작은따옴표, 큰따옴표, 백슬래시와 같이 자바스크립트에서 특별한 의미를 갖는 문자를 이스케이프합니다. JSON.stringify()와 같은 함수나 ESAPI (Encoder)와 같은 라이브러리를 사용합니다.

예제 (자바스크립트 - HTML 인코딩):

function escapeHTML(str) { let div = document.createElement('div'); div.appendChild(document.createTextNode(str)); return div.innerHTML; } let userInput = '<script>alert("XSS");</script>'; let encodedInput = escapeHTML(userInput); // 인코딩된 입력을 DOM에 출력 document.getElementById('output').innerHTML = encodedInput; // 출력: &lt;script&gt;alert("XSS");&lt;/script&gt;

예제 (파이썬 - HTML 인코딩):

import html user_input = '<script>alert("XSS");</script>' encoded_input = html.escape(user_input) print(encoded_input) # 출력: &lt;script&gt;alert("XSS");&lt;/script&gt;

컨텍스트 인식 인코딩

사용하는 인코딩 유형은 데이터가 표시되는 컨텍스트에 따라 다릅니다. 예를 들어, HTML 속성 내에 데이터를 표시하는 경우 HTML 속성 인코딩을 사용해야 합니다. 자바스크립트 문자열 내에 데이터를 표시하는 경우 자바스크립트 문자열 인코딩을 사용해야 합니다.

예제:

<input type="text" value="<?php echo htmlspecialchars($_GET['name'], ENT_QUOTES, 'UTF-8'); ?>">

이 예제에서는 URL의 name 파라미터 값이 input 필드의 value 속성 내에 표시됩니다. htmlspecialchars() 함수는 name 파라미터의 모든 특수 문자가 적절하게 인코딩되도록 하여 XSS 공격을 방지합니다.

템플릿 엔진 사용

많은 현대 웹 프레임워크와 템플릿 엔진(예: React, Angular, Vue.js, Twig, Jinja2)은 자동 출력 인코딩 메커니즘을 제공합니다. 이러한 엔진은 템플릿에서 변수가 렌더링될 때 자동으로 이스케이프하여 XSS 취약점의 위험을 줄여줍니다. 항상 사용하는 템플릿 엔진의 내장 이스케이핑 기능을 사용하세요.

콘텐츠 보안 정책(CSP)

CSP란 무엇인가?

콘텐츠 보안 정책(CSP)은 크로스 사이트 스크립팅(XSS) 및 데이터 주입 공격을 포함한 특정 유형의 공격을 탐지하고 완화하는 데 도움이 되는 추가적인 보안 계층입니다. CSP는 브라우저가 리소스를 로드할 수 있는 소스의 화이트리스트를 정의할 수 있게 함으로써 작동합니다. 이 화이트리스트에는 도메인, 프로토콜, 심지어 특정 URL까지 포함될 수 있습니다.

기본적으로 브라우저는 웹 페이지가 모든 소스에서 리소스를 로드하도록 허용합니다. CSP는 리소스를 로드할 수 있는 소스를 제한하여 이 기본 동작을 변경합니다. 만약 웹사이트가 화이트리스트에 없는 소스에서 리소스를 로드하려고 시도하면, 브라우저는 해당 요청을 차단합니다.

CSP의 작동 방식

CSP는 서버에서 브라우저로 HTTP 응답 헤더를 전송하여 구현됩니다. 이 헤더에는 각 지시어가 특정 리소스 유형에 대한 정책을 지정하는 지시어 목록이 포함되어 있습니다.

CSP 헤더 예제:

Content-Security-Policy: default-src 'self'; script-src 'self' https://example.com; style-src 'self' https://cdn.example.com; img-src 'self' data:; font-src 'self';

이 헤더는 다음 정책들을 정의합니다:

• default-src 'self': 웹 페이지와 동일한 출처(도메인)에서만 리소스를 로드하도록 허용합니다.
• script-src 'self' https://example.com: 동일한 출처와 https://example.com에서만 자바스크립트를 로드하도록 허용합니다.
• style-src 'self' https://cdn.example.com: 동일한 출처와 https://cdn.example.com에서만 CSS를 로드하도록 허용합니다.
• img-src 'self' data:: 동일한 출처와 데이터 URI(base64로 인코딩된 이미지)에서만 이미지를 로드하도록 허용합니다.
• font-src 'self': 동일한 출처에서만 폰트를 로드하도록 허용합니다.

CSP 지시어

다음은 가장 일반적으로 사용되는 CSP 지시어들입니다:

• default-src: 모든 리소스 유형에 대한 기본 정책을 설정합니다.
• script-src: 자바스크립트를 로드할 수 있는 소스를 정의합니다.
• style-src: CSS를 로드할 수 있는 소스를 정의합니다.
• img-src: 이미지를 로드할 수 있는 소스를 정의합니다.
• font-src: 폰트를 로드할 수 있는 소스를 정의합니다.
• connect-src: 클라이언트가 연결할 수 있는 출처를 정의합니다(예: WebSocket, XMLHttpRequest).
• media-src: 오디오 및 비디오를 로드할 수 있는 소스를 정의합니다.
• object-src: 플러그인(예: Flash)을 로드할 수 있는 소스를 정의합니다.
• frame-src: 프레임(<frame>, <iframe>)으로 포함될 수 있는 출처를 정의합니다.
• base-uri: 문서의 <base> 요소에서 사용할 수 있는 URL을 제한합니다.
• form-action: 폼이 제출될 수 있는 URL을 제한합니다.
• upgrade-insecure-requests: 브라우저에게 안전하지 않은 요청(HTTP)을 안전한 요청(HTTPS)으로 자동 업그레이드하도록 지시합니다.
• block-all-mixed-content: 브라우저가 혼합된 콘텐츠(HTTPS를 통해 로드된 HTTP 콘텐츠)를 로드하는 것을 방지합니다.
• report-uri: CSP 정책이 위반될 때 브라우저가 위반 보고서를 전송해야 할 URL을 지정합니다.
• report-to: 위반 보고서를 보낼 엔드포인트를 포함하는 `Report-To` 헤더에 정의된 그룹 이름을 지정합니다. `report-uri`보다 더 현대적이고 유연한 대체재입니다.

CSP 소스 목록 값

각 CSP 지시어는 허용되는 출처나 키워드를 지정하는 소스 값 목록을 받습니다.

• 'self': 웹 페이지와 동일한 출처의 리소스를 허용합니다.
• 'none': 모든 출처의 리소스를 허용하지 않습니다.
• 'unsafe-inline': 인라인 자바스크립트 및 CSS를 허용합니다. XSS에 대한 보호를 약화시키므로 가능한 한 피해야 합니다.
• 'unsafe-eval': eval() 및 관련 함수의 사용을 허용합니다. 보안 취약점을 유발할 수 있으므로 이 역시 피해야 합니다.
• 'strict-dynamic': 논스나 해시를 통해 마크업에서 스크립트에 명시적으로 부여된 신뢰가 해당 루트 스크립트에 의해 로드되는 모든 스크립트로 전파되어야 함을 지정합니다.
• https://example.com: 특정 도메인의 리소스를 허용합니다.
• *.example.com: 특정 도메인의 모든 하위 도메인 리소스를 허용합니다.
• data:: 데이터 URI(base64로 인코딩된 이미지)를 허용합니다.
• mediastream:: `media-src`에 대해 `mediastream:` URI를 허용합니다.
• blob:: `blob:` URI(브라우저 메모리에 저장된 이진 데이터에 사용)를 허용합니다.
• filesystem:: `filesystem:` URI(브라우저의 샌드박스 파일 시스템에 저장된 파일에 접근하는 데 사용)를 허용합니다.
• nonce-{random-value}: 일치하는 nonce 속성을 가진 인라인 스크립트나 스타일을 허용합니다.
• sha256-{hash-value}: 일치하는 sha256 해시를 가진 인라인 스크립트나 스타일을 허용합니다.

CSP 구현하기

CSP를 구현하는 방법에는 여러 가지가 있습니다:

• HTTP 헤더: CSP를 구현하는 가장 일반적인 방법은 서버 응답에 Content-Security-Policy HTTP 헤더를 설정하는 것입니다.
• 메타 태그: CSP는 HTML 문서의 <meta> 태그를 사용하여 정의할 수도 있습니다. 그러나 이 방법은 덜 유연하며 일부 제한이 있습니다(예: frame-ancestors 지시어를 정의하는 데 사용할 수 없음).

예제 (HTTP 헤더를 통한 CSP 설정 - Apache):

Apache 설정 파일(예: .htaccess 또는 httpd.conf)에 다음 줄을 추가합니다:

Header set Content-Security-Policy "default-src 'self'; script-src 'self' https://example.com; style-src 'self' https://cdn.example.com; img-src 'self' data:; font-src 'self';"

예제 (HTTP 헤더를 통한 CSP 설정 - Nginx):

Nginx 설정 파일(예: nginx.conf)의 server 블록에 다음 줄을 추가합니다:

add_header Content-Security-Policy "default-src 'self'; script-src 'self' https://example.com; style-src 'self' https://cdn.example.com; img-src 'self' data:; font-src 'self';";

예제 (메타 태그를 통한 CSP 설정):

<meta http-equiv="Content-Security-Policy" content="default-src 'self'; script-src 'self' https://example.com; style-src 'self' https://cdn.example.com; img-src 'self' data:; font-src 'self';">

CSP 테스트하기

CSP 구현이 예상대로 작동하는지 테스트하는 것이 중요합니다. 브라우저 개발자 도구를 사용하여 Content-Security-Policy 헤더를 검사하고 위반 사항이 있는지 확인할 수 있습니다.

CSP 보고

`report-uri` 또는 `report-to` 지시어를 사용하여 CSP 보고를 설정합니다. 이를 통해 서버는 CSP 정책이 위반될 때 보고서를 받을 수 있습니다. 이 정보는 보안 취약점을 식별하고 수정하는 데 매우 유용할 수 있습니다.

예제 (report-uri를 사용한 CSP):

Content-Security-Policy: default-src 'self'; report-uri /csp-report-endpoint;

예제 (report-to를 사용한 CSP - 더 현대적인 방식):

Report-To: {"group":"csp-endpoint","max_age":10886400,"endpoints":[{"url":"https://your-domain.com/csp-report-endpoint"}]} Content-Security-Policy: default-src 'self'; report-to csp-endpoint;

서버 측 엔드포인트(이 예제에서는 `/csp-report-endpoint`)는 이러한 JSON 보고서를 수신하고 처리하도록 구성되어야 하며, 나중에 분석할 수 있도록 기록해야 합니다.

CSP 모범 사례

• 엄격한 정책으로 시작하기: 동일한 출처의 리소스만 허용하는 제한적인 정책(default-src 'self')으로 시작합니다. 필요에 따라 점차 정책을 완화하고 특정 소스를 추가합니다.
• 'unsafe-inline' 및 'unsafe-eval' 피하기: 이 지시어들은 XSS에 대한 보호를 크게 약화시킵니다. 가능한 한 사용을 피하세요. 인라인 스크립트 및 스타일에 대해서는 논스나 해시를 사용하고, eval() 사용을 피하세요.
• 인라인 스크립트 및 스타일에 논스 또는 해시 사용하기: 인라인 스크립트나 스타일을 반드시 사용해야 하는 경우, 논스나 해시를 사용하여 화이트리스트에 추가하세요.
• CSP 보고 사용하기: 정책이 위반될 때 알림을 받도록 CSP 보고를 설정하세요. 이는 보안 취약점을 식별하고 수정하는 데 도움이 됩니다.
• CSP 구현을 철저히 테스트하기: 브라우저 개발자 도구를 사용하여 Content-Security-Policy 헤더를 검사하고 위반 사항이 있는지 확인하세요.
• CSP 생성기 사용하기: 특정 요구 사항에 따라 CSP 헤더를 생성하는 데 도움이 되는 여러 온라인 도구가 있습니다.
• CSP 보고서 모니터링하기: 정기적으로 CSP 보고서를 검토하여 잠재적인 보안 문제를 식별하고 정책을 개선하세요.
• CSP를 최신 상태로 유지하기: 웹사이트가 발전함에 따라 리소스 의존성의 변경 사항을 반영하도록 CSP를 업데이트해야 합니다.
• 콘텐츠 보안 정책(CSP) 린터 사용 고려하기: `csp-html-webpack-plugin`과 같은 도구나 브라우저 확장 프로그램은 CSP 구성을 검증하고 최적화하는 데 도움이 될 수 있습니다.
• CSP를 점진적으로 적용하기 (보고 전용 모드): 처음에는 `Content-Security-Policy-Report-Only` 헤더를 사용하여 "보고 전용" 모드로 CSP를 배포합니다. 이를 통해 실제로 리소스를 차단하지 않고 잠재적인 정책 위반을 모니터링할 수 있습니다. 보고서를 분석하여 CSP를 미세 조정한 후 강제 적용합니다.

예제 (Nonce 구현):

서버 측 (Nonce 생성):

<?php $nonce = base64_encode(random_bytes(16)); ?>

HTML:

<script nonce="<?php echo $nonce; ?>"> // 여기에 인라인 스크립트 작성 console.log('Nonce를 사용한 인라인 스크립트'); </script>

CSP 헤더:

Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-<?php echo $nonce; ?>';

CSP와 서드파티 라이브러리

서드파티 라이브러리나 CDN을 사용할 때는 해당 도메인을 CSP 정책에 포함시켜야 합니다. 예를 들어, CDN에서 jQuery를 사용하는 경우 CDN의 도메인을 script-src 지시어에 추가해야 합니다.

하지만 전체 CDN을 무턱대고 화이트리스트에 추가하면 보안 위험을 초래할 수 있습니다. 하위 리소스 무결성(SRI)을 사용하여 CDN에서 로드된 파일의 무결성을 확인하는 것을 고려하세요.

하위 리소스 무결성 (SRI)

SRI는 CDN이나 다른 서드파티 소스에서 가져온 파일이 변조되지 않았는지 브라우저가 확인할 수 있게 해주는 보안 기능입니다. SRI는 가져온 파일의 암호화 해시를 알려진 해시와 비교하여 작동합니다. 해시가 일치하지 않으면 브라우저는 파일 로드를 차단합니다.

예제:

<script src="https://example.com/jquery.min.js" integrity="sha384-example-hash" crossorigin="anonymous"></script>

integrity 속성에는 jquery.min.js 파일의 암호화 해시가 포함됩니다. crossorigin 속성은 다른 출처에서 제공되는 파일에 대해 SRI가 작동하는 데 필요합니다.

결론

프론트엔드 보안은 웹 개발의 중요한 측면입니다. XSS 방어 기법과 콘텐츠 보안 정책(CSP)을 이해하고 구현함으로써 공격의 위험을 크게 줄이고 사용자의 데이터를 보호할 수 있습니다. 입력값 검증, 출력 인코딩, CSP 및 기타 보안 모범 사례를 결합한 다층적인 접근 방식을 채택하는 것을 잊지 마세요. 안전하고 견고한 웹 애플리케이션을 구축하기 위해 최신 보안 위협과 완화 기술에 대해 계속 배우고 최신 정보를 유지하세요.

이 가이드는 XSS 방어 및 CSP에 대한 기초적인 이해를 제공합니다. 보안은 지속적인 과정이며, 잠재적인 위협에 앞서 나가기 위해서는 지속적인 학습이 필수적이라는 점을 기억하세요. 이러한 모범 사례를 구현함으로써 사용자를 위해 더 안전하고 신뢰할 수 있는 웹 경험을 만들 수 있습니다.